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REMARKS 

Claims 1, 2, 4, 7-16, 18 and 19 are pending. 

Summary of Telephonic Interview 

The undersigned wishes to thank Examiner Patel and Examiner Baderman for taking 
the time to conduct a telephonic interview on September 16, 2010. During the interview, the 
discussion focused on the differences between the Ritz reference and the applicant's 
invention, as well as potential amendments to the claims that the Examiner felt would more 
clearly claim the invention. 

(Maim Amendments 

The applicant has amended independent claims 1, 14 and 19 to more clearly claim the 
applicant's invention. No new matter has been added due to these amendments and support 
for these amendments can be found throughout the applicant's specification and figures. 

Claim Rejections under 35 U.S.C. §102 

Claims 1, 2, 4, 7-16, 18 and 19 stand rejected under 35 U.S.C. § 102(e) as being 
anticipated by U.S. Patent No. 7,263,632 to Ritz et al. (hereinafter "Ritz"). The Applicant 
disagrees with these rejections and favorable reconsideration is respectfully requested in view 
of the following remarks. 

The applicant points out that independent claims 1, 14 and 19 are amended to include 
the element of dynamically identifying an occurrence of an application exception prior to the 
application exception being sensed by the software application and logged. Ritz clearly does 
not disclose these elements. 

Regarding independent claims 1, 14 and 19, the Office asserts that Ritz discloses that 
"the monitoring service applies policy to filter which events are propagated up to invoke 
diagnostic module for root cause determination" and that this equates to an operating system 
that "is capable of dynamically identifying root cause determination." The applicant 
disagrees and points out that the application exception functions of Ritz are predetermined 
and integrated into the application software (i.e. .NET, Java) by the application developer at 
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the time of development. And, when a predetermined application event occurs, a trigger in 
the application software is activated which causes an application exception to be generated. 
If the event is not coded into the application software, then no trigger will occur and no 
application exception will be generated. This is not equivalent to dynamically determining 
the occurrence of an exception event (that may or may not be predetermined) and Ritz is 
clearly not capable of dynamically determining the occurrence of a non- predetermined 
exception event. In fact, when a predetermined exception event occurs in Ritz, Ritz generates 
an application exception and logs predetermined event information regarding the application 
exception event into an event log, where the exception event information is stored for future 
processing. All of the processing of the predetermined event information is performed after 
it is logged. Because the log is not accessible to the management system software, the 
information in the exception log is not changeable and thus, cannot be added to. Moreover, 
because the exception event is over and the conditions surrounding the event have changed, 
there is no way to gather additional information about the exception event if needed. 

This is completely different from the applicant's invention which addresses the 
situation where a software exception event is not anticipated by the application developer and 
is thus not integrated into the software application as a predefined application event. Ritz is 
not capable of this and any exception event that occurs in Ritz and that is not predefined 
would be unrecognized and no action would be taken. Accordingly, it is clear that Ritz does 
not and cannot dynamically detect an exception event. 

The applicant further points out that Ritz does not identify or distinguish between 
critical exceptions and other exceptions, nor does Ritz determine the type of critical exception 
and process the critical exception responsive to the type of critical exception. For example, 
Ritz clearly does not determine whether an exception is a primary exception or a derived 
exception and in fact makes no mention of critical exceptions, primary exceptions or derived 
exceptions. Rather because all of the actions in Ritz are predetermined by the developer, Ritz 
merely acts as the developer has predetermined (i.e. an exception event occurs and Ritz logs 
the information the developer has requested). Thus no identification or determination occurs 
in Ritz. 
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The Office further attempts to support their position by pointing out that Ritz 

discloses that the logger makes determinations before the event has been logged to the event 

trace log file and directs the applicant's attention to col. 9, lines 6-24 of Ritz which recites: 

If the error event does not have a known root cause associated 
with it, diagnostics module 220 will report this information to the 
activity log 230, which in turn sends an error report 234 to error 
reporting service 238. 

If the vendor is able to determine the root cause from the information 
sent by activity log 230, the root cause association information and 
corresponding problem resolution information is information is sent 
to the computing system 201 via update service 240. If the vendor is 
unable to determine the root cause, the vendor may use update service 
240 to instruct diagnostic policy service 204 to store additional event 
or state information to event trace log file 248. The resolution module 
224 may likewise instruct 260 the logger to store additional events 224 
in order to ensure that proper resolution is achieved. When the additional 
information is transmitted to the error reporting service 238 after the 
next occurrence of the problem, the additional information may enable 
the vendor to better identify the root cause of the problem. 

However, the information that Ritz is discussing above is the information that the 
developer has predetermined in the application software. Thus, the information that is being 
logged includes extraneous information that is not needed and thus is a waste of resources. 
As such, a majority of the predetermined information that is logged in response to a 
predetermined exception event is of no value. The applicant's invention maximizes 
efficiency by allowing only useful information to be logged as opposed to logging 
information that is not useful in determining root cause. 

In light of the above discussion, it is clear that Ritz does not disclose or teach each 
and every element of applicant's amended independent claims 1, 14 and 19. Accordingly, for 
at least the foregoing reasons, the applicant respectfully submits that amended independent 
claims 1, 14 and 19 patentably define over Ritz. Additionally, as claims 2, 4, and 7-13 
depend from amended independent claim 1 and claims 15-16 and 18 depend from amended 
independent claim 14, they too patentably define over Ritz for at least the same reasons. 
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CONCLUSION 

For the foregoing reasons, the applicant respectfully submits that claims 1, 2, 4, 7-16, 
18 and 19 are not anticipated by and are thus patentably distinguishable over Ritz. 
Accordingly, favorable reconsideration and withdrawal of these rejections is respectfully 
requested. Additionally, the applicant submits herewith a request for continued examination 
(RCE) along with a request for a one month's extension of time extending the period for 
response to November 22, 2010 along with the appropriate fees for a large entity. 



Respectfully submitted, 




Steven M. McHugh, Esq. 
USPTO Reg. No. 47,784 
Attorney for the Applicant 
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